New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
After MSRV bump: Implemented TryFrom<{u8, i32}>
for Parity
#409
Conversation
670da82
to
e148753
Compare
Added commit changing |
e148753
to
ca110b8
Compare
This implements `source()` method instead of `cause()` allowing downcasting.
ca110b8
to
df081be
Compare
Rebased, @tcharding my previous PR had cause->source change so I left it in, do you want me to remove it in favor of your PR? |
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK df081be
What was the reason that we could not have If the underlying FFI guarantees that the value is either 1 or 0. We should represent it in an enum. IMO, there is no need to stick to |
Did you get mixed up? We do have an enum
:) |
946cd83 Improve Error display (Tobin C. Harding) Pull request description: Introduce `write_err` macro and improve the `Display` implementation on `Error`. This PR is re-written after review below. The `std::error::Error` implementation is removed in favour of #409. Now only includes the `Display` stuff. ACKs for top commit: apoelstra: ACK 946cd83 nice! Tree-SHA512: a62e9593c2ed1ba6136136e6b575219d68c25736069f55448f8411048efae27f2467bcb65260a78ff065de9c8c2994873804c687fb37a55b705cddfe20544f37
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK df081be
@sanket1729 for the purpose of encoding it in a taproot control block, which requires an integer (a |
Sorry, my local tree was not updated. And I was looking at some old code :(. We might not need the TryFrom from |
@sanket1729 FYI my motivation for adding them is based on the Rust API guidelines (and I agree with that particular recommendation :)) |
@Kixunil for sure -- if we support conversion to/from numerics then we should definitely use |
No description provided.